А что это за сложный селектор такой? Почему просто класс не использовать?

Там должен быть data-role-id, ошибка. Как мне кажется тут уместно использовать data-атрибуты, потому что нам не нужны CSS-селекторы и мы не хотим привязываться ко стилям. Мы хотим достать "input, который для поиска товаров", надежнее всего под это выделить data-атрибут и искать потом по нему, как мне кажется.

.input_type_search решает эту проблему ;)
как минимум, читается это проще

Вроде бы использование конкретных testid'ов в тестах же является common-, если не best-practice. Я вижу такие преимущества использования разметки data-testid над селекторами:

• все data-testid можно вырезать при сборке бандла в прод, а селекторы нет
• селекторы относятся к стилям, если захочется рефакторить стили, поменяются селекторы и все тесты надо будет тоже чинить

Пока что просто поправил на data-testid.

where can I view these rules? can't find them

Here, we extend storybook's webpack config with some custom rules. By adding ...config.module.rules we make sure to include original rules, we don't want to throw them away when adding ours.

Docs: https://storybook.js.org/docs/api/main-config-webpack-final

why do we need to exclude this rule?

Because it conflicts with typescript-eslint, as stated in the comment above. It provides its own rule, @typescript-eslint/no-unusd-vars, because the original one doesn't work well with TS code.

jpg? really? :)

What's wrong with jpg? I'm trying to squeeze assets as tightly as I can so that landing page opens up fast enough even on slow internet. Pics are not of great quality, but good enough for demo purposes, IMO

for better code readability we need to add selectors (for example, .collapsible) instead of leaving empty elements

OK, added unused collapsible class for the sake of better devtools experience and corresponding class names for other components as well. I still think that it kinda diminishes some of the benefits of using Tailwind though

.input_type_search решает эту проблему ;)
как минимум, читается это проще

absolute... again... instead of simple display: inline-block

hmmm, I don't want line numbers to affect code in any way and don't want to deal with inline blocks wrapping/overflowing/etc, that's why I positioned them absolutely. What's the benefit of using inline-block here?

imho, it would be better to move stept to the separate file(files) for more readability

yeah, this thought has crossed my mind, however A LOT of things (many refs, signals, store data, etc.) are used inside steps (via closures), if we move them outside, we'll severely worsen readability in that aspect, so in the end I've decided against it.

Otherwise we'll need to construct a function which takes 20+ params (even if packed into an object) and write corresponding types for them all.

Do you think it's worth it?

80?

added a comment. It's just an arbitrary value, to add some room underneath the line, was chosen by trial and error.